Computer systems execute code that may contain vulnerabilities to attack. For example, a common attack vector of malware is to execute a script that overflows a buffer. In order to reduce susceptibility to attack, software and/or firmware developers may implement code patches for a program. Patching a program traditionally involves updating one or more files on permanent or removable storage that are associated with the program, and then reloading the program into memory to execute the patched program. Reloading the program can be accomplished through a system reboot or reset, or sometimes through simply taking down the program itself and reloading the affected program. In either case, the program experiences “down” time, in which the program execution traditionally must be suspended.
The traditional approach to patching involves loading a patching program that patches a code image on a disk prior to allowing the host operating system to execute the patched program, which is why program execution is traditionally suspended. Additionally, traditional patching methods are dependent on the host operating system, because the patching application executes on the host. Thus, different patches must traditionally be deployed for different operating systems.
Patching programs for security holes, especially for critical security holes that could, for example, enable a destructive self-propagating network worm to spread, has become an accepted inconvenience. However, rebooting a system or suspending and reloading a program do not accommodate high availability servers, in which any down time or unavailability is unacceptable. The unavailability of the system can be costly, even if unavailable for only short periods.